Turnbull China Bikeride/Turnbull China Bikeride - Disc 2.iso/BARNET/ARMLINUX/MAIL/9707/000037_owner-linux-arm…r.rutgers.edu _Fri Jul 4 02:05:27 1997.msg

Internet Message Format | 1997-11-30 | 4KB

Return-Path: <[e-mail]>
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id CAA30401 for <[e-mail]>; Fri, 4 Jul 1997 02:05:26 +0100
Received: from vger.rutgers.edu ([128.6.190.2] EHLO vger.rutgers.edu ident: root [port 12145]) by nic.funet.fi with ESMTP id <15468-27117>; Fri, 4 Jul 1997 04:05:16 +0300
Received: by vger.rutgers.edu id <1003689-30852>; Thu, 3 Jul 1997 21:02:06 -0400
Received: from [e-mail] (port 1167 [192.189.54.18]) by vger.rutgers.edu with ESMTP id <1003691-30852>; Thu, 3 Jul 1997 21:01:50 -0400
Received: from home.cvs.com.au (acc3-ppp26.mel.interconnect.com.au [210.8.0.26]) by tulpi.interconnect.com.au with SMTP id LAA26703
  (8.8.5/IDA-1.6 for <[e-mail]>); Fri, 4 Jul 1997 11:04:28 +1000 (EST)
Message-ID: <[e-mail]>
Date:     Fri, 04 Jul 1997 19:05:27 +1000
From: Charles Esson <[e-mail]>
Organization: Colour Vision Systems
X-Mailer: Mozilla 3.01GoldC-Caldera (X11; I; Linux 2.0.29 i586)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Re ELF
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Status: RO

[e-mail] wrote:
>
> Charles Esson writes:
> > Would this only occure if the same physical address was mapped into
> > different virtual addresses with write enabled.        I see it as a
> > reasonable restiction that virtual be mapped to the real on a one to one
> > basis when write is enabled.
>
> But the cache works on VIRTUAL ADDRESSES NOT PHYSICAL!  If the processor
> finds a cache entry for the virtual (program) address, then it *will*
> use it!  It doesn't care about the mapping.  The reason for this is that
> the processor/cache/mmu work as follows:
>
>         Processor wants to read a word.
>          - cache gets searched (always, whether caching is enabled or not).
>                 if entry is found, use it.
>          - if no entry is found, use the mmu to obtain data.  If caching
>                 is enabled, insert this data into the cache.
>

Yes there is a problem. When you switch task there is no rule which says
that you have to use a different virtual address space if you live with
this restriction then I can't see why the cache will not always reflect
reality. But you do need to alter the read write status of different
areas. It would seem a flush of the tags invalides the data in the cache
so one has to write back the data in the cache before doing such an
operation. To quote the manual:
" a flush whole must be preceeded by a sequence of loads to cause the
cache to write back dirty entries".

If this is the case, I consider all is lost. Up to now I have lived with
a operating system that works with no MMU. I don't see memory
fragmentaiton as a problem, being able to allocate required memory out
of a virtual memory space instead of a real space would be a dream. But
I want to have tasks restricted to there own space, finding bugs that
write into someone elses space can be a problem.

I don't care what anyone says, 16k flush is not the go for real time
work. Look at the code suggested, it's a load, a test, and a branch, I'm
no expert on the timing but my quess is 5 cycles for the memory read (
you have to move from CCLK to MCLK ), 1 for the test and two for the
branch thats 112000 cycles we have 200,000,000 of them a second. Thats
0.5 msec. Even under linux task switches are common events, in a real
time system they are a dime a dozen.

I am depressed.


And